iOS Fastlane打包教程

发表于 | 分类于
iOS Fastlane打包教程

iOS Fastlane打包教程

Fastlane是一套由Ruby编写的自动打包以及分发工具集。它的设计类似于Unix中的shell pipeline，每个功能由特定的工具实现，通过不同的工具的连接组合成强大的功能。

下面这些是Fastlane提供的常用工具：

  • gym: 打包 iOS App，是对xcodebuild的封装

  • match: 用于在团队中同步证书和配置文件的工具

  • deliver: 将应用截图，元数据和 app 上传到 App Store
  • produce: 使用命令行在 iTunes Connect 后台和 Dev Portal 创建新的 iOS app

这里仅仅是列出了最常用的工具，Fastlane标准安装包中的工具非常多，而且还有自定义插件功能，这里就不赘述。

1 安装Fastlane

Fastlane本质是一个Ruby脚本的集合，所以机器上首先得安装Ruby。OS X 10.9(Mavericks)以后默认安装的是 Ruby 2.0 本。可能有些脚本或者工具要求更高的版本，所以安装的时候尽量选最新版的Ruby。

这里用Homebrew作为包管理器来安装Ruby：

1
$brew install ruby

安装完Ruby以后才是我们的主角Fastlane：

1
$sudo gem install fastlane

等安装脚本执行完就可以开始Fastlane之旅啦！

2 Fastlane设置

当Fastlane安装好以后，切换到想要用Fastlane进行打包的工程目录，然后初始化。

1
$fastlane init

输入上面这个命令以后Fastlane会调用交互式脚本会询问你关于App的一些信息，按照实际信息填写完以后会生成下面这个结构的目录

fastlane文件夹里面包含了Appfile、Fastfile等文件，它们其实都是ruby语法的脚本文件。上面这些都不用手动添加，运行对应的工具以后就会由工具自动生成，配置文件按需生成，不运行特定工具就不会有对应配置文件产生，如Matchfile，它在你运行fastlane match并输入相关信息后才会出现。

下面是常见的配置文件的用途：

  • Appfile 记录了app_identifier、apple_id、itc_team_id、team_id等信息
  • Fastfile 最核心的文件。自己编写的Fastlane脚本逻辑都写在这个文件中
  • Matchfile 如果是用Match来管理证书的话会有这个文件，里面记录了Match工具在运行时所需要的app_identifier、team_id、username、git_url等信息

fastlane的很多工具既可以写在Fastfile中当一个函数来调用，也可以直接在shell命令行用fastlane 工具名这种方式当命令来使（实际上是一样的，都是执行了对应的ruby脚本）。

上述文件里的配置信息会同步到Fastfile脚本的执行context中，如果用户在脚本里调用工具时没有指定这些字段的值，就会使用配置文件中的，反之就会以脚本里指定的为准。比如在Appfile中有app_identifier字段，你在Appfile中写的是a，在Fastfile中调用match时如果不写app_identifier就会取Appfile中的值也就是a，如果明确指定app_identifier为b，则会以b为准。不过在脚本中指定app_identifier为新值并不会把Appfile中的也改掉。

除了上面说的以外还有一种情况，就是在Matchfile和Appfile中都指定了app_identifier，这到底以哪个为准？这种情况下会以你运行的命令对应的配置文件为准，比如你运行的是match，它有自己的配置文件Matchfile，则app_identifier会以Matchfile中的为准。如果拿不准的话可以看fastlane的输出log，里面会详细列出脚本执行时的各种环境变量。

3 Fastfile样例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
default_platform :ios


platform :ios do
  before_all do   
    backup_project_info_file()
    cocoapods()
  end

  after_all do |lane|
    restore_project_info_file()
  end

  error do |lane, exception|
    restore_project_info_file()
  end

  desc "Deploy a new enterprise version"
  lane :inhouse do

    #start archive
    build_app(
      workspace: "Demo.xcworkspace",
      scheme: "Demo",
      configuration: "Release",
      clean: true,
      export_options: "./fastlane/EnterpriseExportOptions.plist",
      build_path: "./Build/",
      output_directory: "./Build/",
      include_symbols: false,  #ipa包中包含符号文件
      output_name: "Demo.ipa",
    )

    #make change log from commit history
    log = changelog_from_git_commits(merge_commit_filtering: "exclude_merges")

    #upload to pger
    pgyer(api_key: "api key", user_key: "ukey" ,update_description: log)

    #post notification by dingding
    dingding_noti(
      "./Build/Demo.ipa",  #ipa path
      "",   #ipa url
      "", #icon url
      log #change log
    )
  end
end
1
2
3
lane :inhouse do
    #自定义逻辑
end

上面这个格式就是定义一个action，当你使用fastlane inhouse时里面的自定义代码就会被运行。

这是一个典型的Fastfile逻辑，先是调用build_app来archive并导出ipa文件，再调用changelog_from_git_commits生成change log，然后把ipa上传到蒲公英分发系统，最后再用钉钉通知任务完成。这里是在单个target以及证书和相关profile都配置好的情况下的demo。不过在实际中往往会有动态修改target信息，用match更新证书和profile等逻辑，最终的脚本就要比这个复杂很多。

4 Fastlane+Jenkins

其实Jenkins对移动端的打包支持的并不好，所以在Fastlane成熟以后很多人都把打包逻辑迁移到Fastlane上了。这里Jenkins就演变成变成一个CI控制台，仅仅用来做权限控制和脚本触发器。

Jenkins中集成Fastlane就很简单了，在编译的环节直接调用本地的Fastlane脚本就行。

5 题外话

Fastlane踩坑下来发现这套方案功能确实很强大，然而也很复杂。你得学Ruby（有些逻辑不一定能找到现成的插件，得自己写），然后还得把Fastlane的运行逻辑搞清楚，学习成本还是有一点的。所以Fastlane方案适合产品比较多，发版逻辑比较复杂的中大型公司。

在前几年专门做移动端CI的服务商还还不多，但现在移动领域CI集成方案已经很丰富。并且Xcode Server在经过几个版本的迭代以后基本上已经能满足大部分CI需求。所以Fastlane并非是唯一的选择，根据自己的需求选择合适的方案就行，这篇文章详细介绍了除Fastlane以外其他的CI方案。

引用